APO 使用快速定 位故障实践
服务和请求端点的展示规则
首页呈现了服务名和请求端点，排序规则如下：
- 请求端点的延时和错误率在日同比或者周同比超出阀值了会排在上面。在同一个服务内，超过阀值的请求端点排在上面，如果没有超过阀值，按照字母序排序，可能就不会出现在首页，需要点击更多才能看到该请求端点。
- 不同服务节点都有请求端点延时或者错误同比超过阀值的，按照后续服务维度的告警排序：哪个服务亮的红灯多，哪个服务排在上面。如果亮的灯数一样，服务按照字母序排序。日志告警、基础设施告警 权重是一样的。
快速定位到疑似故障服务
根据服务和请求端点的展示规则，排在第一的服务请求端点就是用户需要检查的。
快速判断业务是否正常
根据服务请求端点的延时和错误率判断，如果延 时和错误率和同比没有大范围变化，可以认为该服务请求端点所代表的业务是正常的，即便这个服务节点有一些告警亮灯，比如基础设施告警、日志告警等。是否需要马上点击请求端点详情查看，取决于公司的稳定性策略，如果想要防微杜渐，可以点击详情按照后续章节排查问题。
反之，如果请求端点的延时和错误率同比有超过阀值的变化，则认为业务是不正常的，即便这个服务没有任何告警亮灯也是不正常，需要马上点击请求端点详情，进行快速的故障定界与定位。
如果多个服务同时延时和错误率飘红，该如何快速定位最可疑的服务节点？
每个服务的请求端点都有一个延时来源：来源有两个选项，一个是自身，一个是依赖。
如果一个服务的请求端点延时来源是自身，则该服务的可疑性很高，反之说明延时来源主要是下游依赖，可能是中间件也可能是下游依赖的微服务节点。
如果所有的服务请求端点延时来源都不是自身，而是依赖，但是延时和错误率又有飘红，说明故障来源于所有服务都依赖的中间件或者数据库，这个时候只需要点击排在第一位服务请求端点详情，然后在故障时间范围内，找到任意一条trace，看trace数据访问了哪些中间件即可快速定位哪些中间件有问题了。
不同服务维度的告警需要查看的数据对应关系
日志告警飙升
说明日志中反应的exception和error数量飙升了，此时点击服务请求端点详情，找到错误示例tab
展开该tab，然后选择时间飙升对应的时间段查看日志，分析到底日志发生了什么。
基础设施告警亮红灯
说明基础设施也就是服务实例所在的CPU、内存、磁盘使用量、网络带宽使用量超出阀值，此时点击服务请求端点详情，找到用户自定义大盘
展开该tab，重点分析这些指标，查看哪些实例所在机器的资源是超出了阀值，然后可以进一步登录到该机器上，排查具体的故障根因
网络告警亮红灯
说明服务节点与下游依赖节点的网络质量出现了持续1分钟超过10ms的情况，因为网络质量出现问题，绝大部分是和请求端点无关的，而且影响的节点很少是点对点的两个点，而是大片面积受影响，所以网络告警红灯放置于服务层面上而不是请求端点层面。此时点击服务请求端点详情，找到用户自定义大盘。
展开该tab，重点分析网络延时曲线，找到那两个IP之间的网络延时高了。如果在公有云上，可以提工单，如果自建机房，可以交由负责维护网络的同事继续排查。
K8S事件亮红灯
说明该服务的示例所在pod出现了一些关键k8s事件，此时点击服务请求端点详情，找到k8s事件tab
展开该tab，重点查看k8s相关事件，比如pod是否重启，退出，OOM等
部署时间或者重启时间
如果服务请求端点延时和错误率同比超出了阀值，从部署时间看离故障发生时间很接近，说明故障很可能是由于部署变更导致的，此时可以执行回滚。同时也可以点击服务请求端点详情，查看变更到底引起了什么变化。重点查看错误实例tab中的日志和北极星指标，理解延时是由于什么原因导致的。
服务请求端点详情使用说明
根据拓扑和延时曲线找到更值得怀疑的故障服务。
上下游拓扑
由于拓扑结构在微服务节点非常多之时，非常难使用，所以目前APO只在详情中显示服务的上下游服务，确认上下游服务有没有变化。
依赖节点延时曲线对比图
在拓扑图中查看很多服务很难，但是将延时曲线显示在一张图就容易很多，只需要查看服务的依赖延时曲线是否和查看的服务延时曲线近似即可，依赖服务曲线越近似，依赖服务就越可疑，应该优先排查。
如果依赖服务延时曲线都不近似，就没有必要排查下游服务依赖了。
北极星因果指标的主因的使用
如果在首页确认了错误率有升高，此时应该查看错误实例tab，重点从日志中找到故障原因，如果是延时有升高，就应该重点查看北极星因果指标，北极星因果指标，会帮助判断到底延时来源于什么，由于eBPF采集的内核数据可能比较难以理解，以下是对应代码的方向：
- CPU时间高：代码嵌套循环太多
- gc和lock高：代码锁（包括GC，数据连接池争抢锁都在这里）
- file高：存储故障 （磁盘故障）或者读写了非常大的文件
- net和epoll搞：下游依赖（中间件故障、服务故障）根据ping包数据排除网络质量故障
- runQ：CPU资源不足（其它程序抢占了CPU或者容器的limit配置不合理）
- other：物理内存不足
日志和链路的查看
APO在这两个tab之前应该已经帮助用户对故障定界和定位了，但是有些场景用户仍然想查看日志和链路，可以在这两个tab查和此服务相关的故障现场trace和故障现场log
日志和链路查看思路是一样的：
会按照时间呈现给用户 日志告警的曲线、延时曲线、错误率变化曲线，用户可以根据这个曲线变化，找到关键时间点，查看相关时间点的故障现场trace或者日志。
什么是关键时间点？ 一般关键时间点有以下几种选择：
- 曲线的最高点
- 曲线斜率变化最大的时间点
用户也可以根据自己的理解选择不同的时间点查看故障现场的日志和故障现场的trace